从文字为思维建模：EchoPath Labs 是我的第一步

我最终想做的，是通过人类表达的文字，为人的思维方式建模。

文字里留下了一个人如何观察世界的痕迹：他先注意到什么，怎样界定一个问题，认为哪些证据重要，如何在冲突的解释之间作出选择，又在什么情况下愿意修正自己的判断。

我希望逐渐理解这些联系，让它们成为可以被回看、质疑和持续修正的模型。这样的模型，应当能帮助我们重新理解自己的判断，也帮助 AI 在长期协作中更好地接续一个人的思考。

EchoPath Labs 是我朝这个方向踏出的第一步。 我先从自己持续投入的软件工程与人机协作出发，尝试把表达、理解、行动和反馈之间的关系保留下来。

文字怎样留下思维的痕迹

在 JanusPath 的写作中，我持续关心观察方式、结构与行动之间的关系。面对同一件事，不同的人可能从完全不同的位置开始思考。

有人先问结果能不能更快交付，有人先问这个问题为什么会出现，也有人首先关心谁有权作出决定。这些提问所关注的对象不同，会进一步影响证据的选择、问题的拆分与方案的取舍。

当一个人在需求说明、方案讨论、代码审查和事后复盘中反复表达自己的判断时，这些文字便提供了一组可以研究的线索：

注意与观察： 哪些现象会先进入他的视野？
概念与关系： 他习惯用哪些概念组织问题，把哪些事情联系起来？
判断与取舍： 他依据什么接受一个解释，又如何处理相互冲突的目标？
修正与延续： 遇到新证据以后，他改变了什么，保留了什么？

这些是我希望逐渐建模的对象。它们需要放回具体情境中理解：一段话可能是临时设想，也可能是在转述别人的观点；一次方案选择可能受限于时间，而不能直接说明一个人始终如此思考。

因此，我设想的模型必须保留来源、情境和不确定性，允许当事人纠正，也要能够随着后续表达与实践而更新。能解释一次选择，只是起点；能否在新的情境中继续帮助理解，还需要检验。

为什么第一步落在工程协作中

工程工作提供了一条相对清楚的观察路径。

一个人提出目标，用文字解释问题，讨论边界与取舍；Agent 据此行动，留下修改、测试和结果；人再判断这些结果是否符合原意，有时也会因此重新定义问题。

这让表达有机会与后续行动相互对照。比如，一个人说“保持简单”，究竟在意的是代码量、使用成本，还是未来修改时需要同时理解的东西？仅凭这几个字，很难知道。看他如何评审具体方案、接受哪些代价、如何解释一次返工，理解才可能逐渐变得准确。

我选择从这里开始，是因为这些材料可以在持续工作的过程中形成，也有相对具体的结果帮助核对。文字是观察入口，行动与反馈则帮助检验我们对文字的理解。

当然，工程场景只能提供一部分材料。它还不足以代表一个人在其他情境中的思维方式。从这里形成的方法能否扩展，是后续需要继续探索的问题。

在走向这个目标之前，我需要先解决一些基础问题：概念从哪里来，哪些判断已经确认，行动是否遵循了当时的边界，以及后来怎样找回这些联系。

EchoPath Labs 的几个项目，便从这些问题中逐渐展开。其中，EchoPath Labs 是整组项目的名称，EchoPath 则是专门承担认知连续性的产品。

五个项目，各自回答一个问题

理解这个体系，可以先抓住三个词：意义、行动、连续性。

OpenDomain 关注意义：我们正在处理的世界有哪些概念和规则。RelayPact 关注行动：一次任务怎样被委派、执行和验收。EchoPath 关注连续性：工作为什么走到这里，下一次怎样接得上。

围绕这条主线，ForgeRail 提供工程治理，KeptNear 提供受控的凭据使用能力。

EchoPath Labs 体系关系图：OpenDomain 提供领域语义，ForgeRail 提供治理约束，KeptNear 提供凭据使用能力，RelayPact 承担受控行动，EchoPath 保存连续性并形成返回 OpenDomain 的候选洞见。

这张图表达的是我正在构建的职责关系与组合方向，不代表五个产品已经形成自动运行的完整集成。

OpenDomain：让概念与规则有稳定的出处

假设我们在开发一个订单系统。“取消订单”是否意味着退款？已经发货的订单能不能取消？这类问题决定的是业务含义，不能只靠某一次对话中的解释。

OpenDomain 把长期有效的领域概念、规则、生命周期和证据保存在可以被 Git 管理的 Markdown 与 YAML 中。人在维护项目，Agent 在执行任务，都可以回到同一份来源核对理解。

这里有一个对我很重要的区分：已经接受的知识，与有待确认的推断，必须分开。 Agent 从代码中发现了一条可能的规则，可以提出候选知识，附上依据；它不会仅仅因为解释得通，就自动成为新的业务定义。公开实现也保留了候选审查与正式纳入领域知识的边界。OpenDomain 项目说明

ForgeRail：让工作遵循当前项目的工程边界

理解业务以后，还需要知道这次工作应当怎样推进。

哪些现有约定适用？可以修改哪些内容？需要运行什么验证？哪些操作仍然需要人的决定？ForgeRail 关注这些工程问题。它从工作区已有的说明、规范和证据出发，为 Coding Agent 提供适度的引导与约束。

我希望工程治理的分量与问题相称。一次简单修改不需要凭空长出一套流程；涉及较大风险的变更，则需要把范围、验证和交接说清楚。当前 ForgeRail 的公开 alpha 也沿着这种渐进采用的方式展开。ForgeRail 项目说明

RelayPact：让一次委派有范围，也有验收

当工作适合交给另一个 Agent 时，RelayPact 负责把这次委派变得明确：任务是什么，可以读取什么，可以修改什么，结果需要带回哪些证据。

执行者报告完成之后，协调者还需要审查实际产物。执行完成、接受结果、把改动应用到源代码，是不同的步骤。 一个“完成了”的回复，不能代替对修改范围与验证结果的判断。

RelayPact 目前公开验证的主线是 Codex 到 Codex 的有界委派。我关心的是协作关系能否被说清楚、检查和收束，而不只是同时启动更多执行者。RelayPact 项目说明

KeptNear：把凭据使用限制在具体操作中

Agent 执行任务时，有时需要调用 API 或访问外部服务。这个需求会把另一个问题带进来：怎样使用凭据，才不会让原始秘密散落在提示词、聊天记录和普通工具输出里？

KeptNear 本身是一个本地优先的密码与 Token 管理器。在这个体系中，它承担的角色更窄：围绕选定的凭据字段、应用和操作，提供经过授权的使用能力。

凭据可用，也只说明某种访问条件具备了。它不表示这次业务操作已经获准，更不表示 Agent 可以自行发布。当前相关 Broker、MCP 和 CLI 能力仍处于源码级开发者预览，不能把这条设计路径理解为已经面向普通用户交付的完整流程。KeptNear 能力状态

EchoPath：让下一次工作能够恢复理解

EchoPath 关注工作结束之后，哪些东西需要留下，以及以后怎样重新理解它们。

只有一段“做了什么”的总结往往不够。我们还需要知道当时的目标、依据、选择、结果，以及仍然没有解决的差异。EchoPath 的 Project Compass，也就是“项目罗盘”，希望帮助人和 Agent 找回项目当前位置、形成这个状态的原因与下一步。

这里的因果历史，需要有证据边界。文件发生过修改、测试产生了某个结果，可以被观察；“为什么作出这个选择”，需要显式说明或决策记录。缺少依据的解释，应当保留为可以审查的候选，不能伪装成确定的历史。EchoPath 依据工作区证据、Agent 的显式回报和人的确认展开工作。

我正在验证的核心，是让一次协作从理解任务、确认边界、执行与核对结果，走到可恢复的收束，再成为下一次工作的起点。

把它们放进同一次工作里

仍以订单系统为例。下面是一个说明组合方向的假设场景，并非已经交付的五产品自动化演示。

现在需要调整“订单取消”的行为。

开始时，我们先核对 OpenDomain 中已经接受的订单规则。假如文档没有说清楚发货后的取消条件，就把这个缺口明确提出来，请业务负责人判断，而不是让 Agent 在实现过程中顺手补出一个定义。

与此同时，EchoPath 可以为这次任务恢复相关历史：以前考虑过什么方案，哪些约束仍然适用，哪些证据需要重新检查。过去做过的决定可以帮助理解现在，但过去的许可不能直接充当本次操作的授权。

接着，ForgeRail 根据当前项目约定梳理修改范围、验证要求和需要确认的操作。若其中一项工作适合委派，再由 RelayPact 交给独立执行者，并保留协调者对产物的审查。如果任务需要外部凭据，KeptNear 的组合方向是按已批准的范围提供使用能力；不需要凭据时，这个环节就不参与。

结果回来以后，检查也不能停在“测试通过”这四个字。实际修改是否符合任务？有没有遗漏的行为？哪些判断仍然只是推断？确认过的结果与未决问题，才是后续恢复工作需要的材料。

如果这次工作让我们发现一条更普遍的领域规则，它可以进入 OpenDomain 的候选审查。经过确认，才可能成为以后任务可以依赖的知识。

这样，一次行动除了交付代码，也有机会留下更清楚的理解。经验经过核对以后，才逐步进入结构。

为什么要让它们保持独立

我用“可组合自治”描述这个体系的设计原则：每个产品独立解决一个完整问题，组合发生在清晰的接口与证据边界上。

只想维护业务概念的人，应当可以单独使用 OpenDomain；需要委派任务的人，可以独立使用 RelayPact；KeptNear 的密码管理也有自己的使用价值。EchoPath 的连续性工作，同样不应以“所有行动都经过 RelayPact”为前提。

这种独立性也要求尊重各自的职责。一次工程检查通过，不能代替业务知识的确认；一个执行结果被接受，不能自动变成发布许可；EchoPath 保存了某次授权的历史，也不代表那份授权现在仍然有效。

在我的组合设计里，各产品交换带有来源与版本的结果和证据引用，原本负责某种事实的产品继续维护它。缺少一项集成时，应当明确说明缺失及其影响，而不是把“没有读到历史”解释成“从来没有历史”。

我希望这种结构允许每个工具继续演进，也允许使用者只选择自己真正需要的部分。

现在走到了哪里

截至 2026 年 9 月 7 日，这些项目的成熟度并不相同：

项目	当前进展
OpenDomain	已发布 v0.1.0 稳定版，提供领域建模、校验、候选审查和上下文导出等能力。
ForgeRail	当前公开预发布为 v0.1.0-alpha.4，Codex 是已验证的宿主。
RelayPact	当前为 v0.1.2 Public Preview，公开主线是 Codex 到 Codex 的委派与审查。
KeptNear	当前为 v0.1.0-prealpha.2 实验性预览。尚未经过外部安全审计，不适合保管生产凭据；机器访问流程仍是开发者预览。
EchoPath	仍在本地开发与自身工作区验证中，重点是认知连续性的完整循环。